Business Intelligence generally refers to software tools used to improve business enterprise decision-making. These tools are commonly applied to financial, human resource, marketing, sales, customer, and supplier analyses. More specifically, these tools can include: reporting and analysis tools to present information; content delivery infrastructure systems for delivery and management of reports and analytics; data warehousing systems for cleansing and consolidating information from disparate sources; and, data management systems, such as relational databases or On Line Analytic Processing (OLAP) systems used to collect, store, and manage raw data.
There are a number of commercially available products to produce reports from stored data. For instance, Business Objects Americas of San Jose, Calif., an SAP company, sells a number of widely used report generation products, including Crystal Reports™, Business Objects Voyager™, Business Objects Web Intelligence™, and Business Objects Enterprise™. As used herein, the term report refers to information automatically retrieved (i.e., in response to computer executable instructions) from a data source (e.g., a database, a data warehouse, a plurality of reports, and the like, where the information is structured in accordance with a report schema that specifies the form in which the information should be presented. A non-report is an electronic document that is constructed without the automatic retrieval of information from a data source. Examples of non-report electronic documents include typical business application documents, such as a word processor document, a presentation document, and the like.
A report document specifies how to access data and format it. A report document where the content does not include external data, either saved within the report or accessed live, is a template document for a report rather than a report document. Unlike, other non-report documents that may optionally import external data within a document, a report document by design is primarily a medium for accessing and, formatting, transforming and or presenting external data.
A report is specifically designed to facilitate working with external data sources. In addition to information regarding external data source connection drivers, the report may specify advanced filtering of data, information for combining data from different external data sources, information for updating join structures and relationships in report data, and instructions including logic to support a more complex internal data model (that may include additional constraints, relationships, and (metadata).
In contrast to a spreadsheet type application, a report generation tool is generally not limited to a table structure but can support a range of structures, such as sections, cross-tables, synchronized tables, sub-reports, hybrid charts, and the like. A report design tool is designed primarily to support imported external data, whereas a spreadsheet application equally facilitates manually entered data and imported data. In both cases, a spreadsheet application applies a spatial logic that is based on the table cell layout within the spreadsheet in order to interpret data and perform calculations on the data. In contrast, a report design tool is not limited to logic that is based on the display of the data, but rather can interpret the data and perform calculations based on the original (or a redefined) data structure and meaning of the imported data. The report may also interpret the data and perform calculations based on pre-existing relationships between elements of imported data. Spreadsheets applications generally work within a looping calculation model, whereas a report generation tool may support a range of calculation models. Although there may be an overlap in the function of a spreadsheet document and a report document, the applications used to generate these documents contain instructions with express different assumptions concerning the existence of an external data source and different logical approaches to interpreting and manipulating imported data.
There are a number of problems associated with existing report generation techniques. For example, in many instances, reports are designed to have salient information as well as detailed information. Some users may wish to view a report in its entirety, while other users may wish to simply view the salient information included in the report. Further, in a multi-user environment, one or more users may wish to execute multiple database queries related to a single report at the same time. In such a scenario, a user attempting to view a report in its entirety may block users who only wish to view portions of a report. In some known report generation tools, a plurality of view requests may also block a user attempting to export an entire report. In these tools it is often the case that exporting an entire report is assumed to take longer than viewing portions of a report. Another prior art report generation problem is data proliferation. In order to service multiple users requesting concurrent access to database queries related to a report, temporary copies of the report file and the saved query data are typically generated so that the data between multiple users can be shared safely. That is, the sharing of results is performed by cloning temporary copies of the report file once it has been identified that there are multiple requesters requiring concurrent access to the report data. This means that entire copies of the report and the saved query data are required to service the concurrent requests, leading to high disk storage requirements.
It would be desirable to develop a technique for sharing reports and database query results among many users in a multi-user environment, so that multiple concurrent requests for report data may be serviced to multiple requestors efficiently and with reduced latency.